Why? This makes debugging worse as we loosing information.

Why? This makes debugging worse as we loosing information.

hi @garydgregory , instead of AbstractConfiguration , shall I put my changes to all derived classes so that it can retain the additional info of subclasses.

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	✅
build-ubuntu-latest	clean install	3.9.8	✅
build-windows-latest	clean install	3.9.8	✅

Generated by gradle/develocity-actions

I am still -1 here: toString() is for debugging. If a call site needs a different view on the object, then it can call another method on that object or build that view (like a String) itself.

Hi @anindita-sarkarArray,

I discussed this with @garydgregory, and I agree that the toString() methods should remain unchanged to preserve a better debugging experience within IDEs.

Following the discussion in #3100, I also think it's a good idea to reduce verbosity in Log4j Core by default. With that in mind, I propose the following:

1. Downgrade the log level of the INFO messages I added in LoggerContext and AbstractConfiguration to DEBUG, with one exception:

   • Keep the INFO message at:
     

     logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/config/AbstractConfiguration.java

     Lines 328 to 334 in 422c385

     	if (isConfigurationMonitoringEnabled()) {
     	LOGGER.info(
     	"Start watching for changes to {} every {} seconds",
     	watchManager.getConfigurationWatchers().keySet(),
     	watchManager.getIntervalSeconds());
     	watchManager.start();
     	}

2. Add an INFO message in LoggerContext.setConfiguration(Configuration) to notify users when a new configuration becomes active (i.e., after the updateLoggers() call). The message could be formatted like:

   <logger_context_class_name>[name=<name>] is using <configuration_class_name>[location=<location>, lastModified=<last_modified>].
   

Let me know what you think.